Enhance message picker & fire new event for `banner:sign-in-gate` by cemms1 · Pull Request #15380 · guardian/dotcom-rendering

cemms1 · 2026-02-17T17:00:59Z

What does this change?

Reworks the messagePicker return type to include metadata on which message was picked and which type of message was picked.
The return type was previously just the component to be rendered but it now includes the following:
```
/** Acts as discriminator to distinguish which type of event was returned */
type: "MessageSelected" | "NoMessageSelected"; 
/** The ID of the picked message */
messageId: string;
/** The resulting component to render ie. the picked message itself */
SelectedMessage: () => MaybeFC
```
This allows us to remove the defaultShow (which is a function that returns null) in favour of the type NoMessageSelected which is much more explicit about what is happening under the hood.
It also allows us to safely distinguish between the CMP result (which returns null because it's handled by a separate process) and the defaultShow result, which happens when no message has been picked.
Updates the expected type of picked message to render to be ReactNode rather than FC to be more flexible with the rest of the codebase
Updates the logic for firing the custom event within StickyBottomBanner to use the discriminated union to check which type of message has been picked.
Also fires a new custom event when the picked message is the sign in gate, since we have decided to explicitly ignore this in the commercial code.

Note

Companion PR in commercial guardian/commercial#2421

Why?

The mobile-sticky slot can sometimes launch at the same time as the CMP and supporter revenue banners. When this happens, the slot is present in the DOM but sits underneath these elements. We can't continue to allow this to happen as impressions are counted against the advert in the slot even though it can't be seen by the end user

We have decided to only allow the mobile-sticky to launch after certain events as well as the existing page conditions.

It is worth noting that we deliberately allow display of the mobile-sticky slot when the sign in gate is the chosen message from the StickyBottomBanner component. The sign in gate currently appears most often obscuring the article body and does not look like a banner or a modal. Another version of the sign in gate appears as a modal and we may want to look into preventing ads running when this is present on the screen.

Co-authored by: @tomrf1

Document link for extra information

github-actions · 2026-02-17T17:21:14Z

Deploy build 24962 of `dotcom:rendering-all` to CODE

All deployment options

From guardian/actions-riff-raff.

dskamiotis · 2026-02-19T09:57:53Z

dotcom-rendering/src/components/SlotBodyEnd.importable.tsx

+			.then((result) => {
+				if (result.type === 'MessageSelected') {
+					setSelectedEpic(result.SelectedMessage);
+				} else {
+					setSelectedEpic(() => null);
+				}
+			})


This is a really sensible approach, and it makes the process much clearer 👍

It might be helpful to add a link to Tom's PR in the description for context, so others can easily reference the related implementation.

dskamiotis · 2026-02-19T09:59:00Z

dotcom-rendering/src/components/StickyBottomBanner.importable.tsx

-	const [hasPickMessageCompleted, setHasPickMessageCompleted] =
-		useState<boolean>(false);
+	const [pickMessageResult, setPickMessageResult] =
+		useState<PickMessageResult | null>(null);


In addition, this is super helpful in addressing the ambiguity around the null value issue.

github-actions · 2026-02-19T11:00:22Z

Deploy build 776 of `dotcom:ab-testing` to CODE

All deployment options

From guardian/actions-riff-raff.

dskamiotis · 2026-02-19T13:13:50Z

dotcom-rendering/src/lib/messagePicker.test.tsx

 		};

-		const got = await pickMessage(config, 'Web');
+		const pickMessageResult = await pickMessage(config, 'Web');


This is really clear naming and helpful for debugging.

dskamiotis · 2026-02-19T13:41:24Z

dotcom-rendering/src/components/StickyBottomBanner.importable.tsx

+	 */
 	useEffect(() => {
-		if (hasPickMessageCompleted && SelectedBanner == null) {
+		if (pickMessageResult?.type === 'NoMessageSelected') {


I'm assuming this will indirectly prevent the mobile-sticky ad from loading when the CMP banner renders, as it will infer NoMessageSelected.

Not quite. In the commercial PR we choose to launch the mobile-sticky slot when the banner:none event is received (so when the result.type is NoMessageSelected).
NoMessageSelected means that we could show the mobile-sticky ad.

What happens for the CMP is that the picked message is cmpUi so the messagePicked would return the following:

{ type: "MessageSelected", id: "cmpUi", SelectedMessage: () => null, // or whatever actually happens when the CMP launches! }

This results in no mobile-sticky ad allowed to be shown because we are not firing any of the following events: banner:none, banner:close, banner:sign-in-gate

Thanks for clarifying, that makes sense now!
So for the CMP case, since the cmpUi message is selected, no banner:none event is fired, which ensures the mobile-sticky ad doesn't load.
This distinction between NoMessageSelected and cmpUi is really helpful to understand the behaviour. Thanks for explaining! 👍

github-actions · 2026-02-19T13:50:25Z

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

…ne for the sign in gate

…the purpose of the events

…n itself

tomrf1

👍

cemms1 force-pushed the cemms1/enhance-message-picker branch from 22449bc to 8b278f4 Compare February 17, 2026 17:16

dskamiotis reviewed Feb 19, 2026

View reviewed changes

cemms1 force-pushed the cemms1/enhance-message-picker branch from 77a342a to e5992f7 Compare February 19, 2026 10:58

dskamiotis reviewed Feb 19, 2026

View reviewed changes

cemms1 mentioned this pull request Feb 19, 2026

Reimplement event handler for mobile sticky slot guardian/commercial#2421

Open

dskamiotis reviewed Feb 19, 2026

View reviewed changes

cemms1 requested review from a team and tomrf1 February 19, 2026 13:50

cemms1 marked this pull request as ready for review February 19, 2026 13:50

cemms1 added the maintenance Departmental tracking: maintenance work, not a fix or a feature label Feb 19, 2026

cemms1 changed the title ~~Enhance message picker~~ Enhance message picker & fire new event for banner:sign-in-gate Feb 19, 2026

tomrf1 and others added 10 commits February 19, 2026 13:53

WIP - clearer messagePicker result

cff5fd6

fix tests

d2e75f7

fix epic

90991ec

tidy up + add logging to view picked message in browser

084b531

fix types

89b4eaa

temporarily skip failing tests

df188e3

add additional metadata to PickMessageResult so we can fire banner:no…

d3bb64b

…ne for the sign in gate

fire separate event for the sign in gate + update comment explaining …

f52caa6

…the purpose of the events

update tests for messagePicker & remove console logs from the functio…

5a059da

…n itself

return NoMessageSelected if errors in result handling

4f5b364

cemms1 force-pushed the cemms1/enhance-message-picker branch from a61ccf8 to 4f5b364 Compare February 19, 2026 13:53

tomrf1 approved these changes Feb 19, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

Enhance message picker & fire new event for `banner:sign-in-gate`#15380

Enhance message picker & fire new event for `banner:sign-in-gate`#15380
cemms1 wants to merge 10 commits intomainfrom
cemms1/enhance-message-picker

cemms1 commented Feb 17, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Feb 17, 2026 •

edited

Loading

Uh oh!

dskamiotis Feb 19, 2026 •

edited

Loading

Uh oh!

dskamiotis Feb 19, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Feb 19, 2026

Uh oh!

dskamiotis Feb 19, 2026

Uh oh!

dskamiotis Feb 19, 2026

Uh oh!

cemms1 Feb 19, 2026

Uh oh!

dskamiotis Feb 19, 2026

Uh oh!

github-actions bot commented Feb 19, 2026

Uh oh!

tomrf1 left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

Conversation

cemms1 commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this change?

Why?

Uh oh!

github-actions bot commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploy build 24962 of dotcom:rendering-all to CODE

Uh oh!

dskamiotis Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dskamiotis Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Feb 19, 2026

Deploy build 776 of dotcom:ab-testing to CODE

Uh oh!

dskamiotis Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

dskamiotis Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

cemms1 Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

dskamiotis Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Feb 19, 2026

Uh oh!

tomrf1 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cemms1 commented Feb 17, 2026 •

edited

Loading

github-actions bot commented Feb 17, 2026 •

edited

Loading

Deploy build 24962 of `dotcom:rendering-all` to CODE

dskamiotis Feb 19, 2026 •

edited

Loading

dskamiotis Feb 19, 2026 •

edited

Loading

Deploy build 776 of `dotcom:ab-testing` to CODE